Many client and server software products have a set of activities, called tasks, which are typically performed by administrators in order to install, manage and maintain the products. Examples of server tasks include setup tasks (e.g., activities performed to install a product), management tasks (e.g., activities performed to configure a product), monitoring/logging/eventing tasks (e.g., activities performed during the regular operation of the product), and maintenance/upgrade/repair task (e.g., activities performed while maintaining the product).
These server tasks are typically exposed from various clients. For example, a setup module may display or expose the setup tasks, a management console may display the management tasks, a monitoring application may display the monitoring/logging tasks, etc. Each of these applications, also referred to as task clients (or clients or task applications), requires knowledge of the tasks the application is to expose, how the application is to collect or receive the input arguments for these tasks, how the application is to launch these tasks, etc. In order for an application to display a task, the requisite knowledge of the task needs to be built—i.e., programmed or coded—into the application, typically before the launch of the product.
A drawback to this conventional approach of displaying tasks by task clients is that the knowledge of the tasks needs to be built into the task clients. In order to for an existing task client to display a newly developed task, new code needs to be written into the task client. Similarly, the conventional approach of embedding the knowledge of the tasks into the task clients does not provide an extensible mechanism for third party task developers who write tasks to integrate their tasks into the same task clients that expose the product tasks—i.e., the task clients provided with the product. Another drawback to the conventional approach is that a task is tied to a particular task client. In order for an additional task client to also display the same task, the task launch code needs to be re-written and incorporated into the additional task client.
Another drawback to the conventional approach is that since the knowledge of which tasks to expose from which task clients is embedded deep within the product, the exposure of the tasks from the task clients cannot be changed once the product is developed. For example, a product's management console may expose a configuration task that helps an administrator set the initial configuration right after product installation. If the administrator subsequently decides that the configuration task is no longer useful in his enterprise, for example, because it has been a year since the product was installed and configured and it has been working flawlessly since then, there is no way for the administrator to remove that task from the management console.
Moreover, the code that implements the tasks is typically shipped with the product and is tightly coupled to the product code and logic. Making any changes to the task code requires re-compiling, re-packaging, and re-shipping the entire module or product code. For example, a setup task that prepares a machine, such as a computer system, by creating accounts and file directories to make the machine suitable for product installation, may be written and shipped in a setup module of a product before the product is shipped. If a change needs to be made to the setup task, for example, to create an extra account, the entire setup module would have to be re-compiled and re-shipped.
Another drawback to the traditional approach of tightly coupling the task code and the product code is that it does not allow third party task developers to write tasks and integrate them into the existing modules of a product. For example, if a third party partner decides to write an extension—i.e., a third party task—to a product, they would have to provide their own system for installing, managing, maintaining and monitoring this extension. As a result, an administrator of the product will not have an integrated experience for setting-up/managing the product and for setting-up/managing the third party extension.
It would be desirable to have a technique that allows for specifying task display and launch sequences in a manner that decouples the task launch code from the task client code. It will also be desirable to have a technique that provides for rapid task deployment into existing task clients.